Broadband subscribers and other business customers of Internet Service Providers (ISPs) use a wide variety of applications and services. Some of the traffic that ISPs carry will have originated from inside the ISP network, for example from other subscribers of the same ISP or from ISP-owned services such as Internet Protocol Television (IP TV). Other traffic will have originated in the Internet and may arrive at the ISP via one of a number of “transit” and “peering” interfaces. Traditionally, the term “transit” is used to describe a network operator that does not have its own subscribers (and therefore generally requires payment to send or receive traffic) whereas the term “peering” refers to similar network providers sharing traffic in a bilateral arrangement for delivery within their own network.
The amount of traffic arriving over such transit and peering interfaces is closely monitored, either to check compliance with a policy or to calculate charges. Such arrangements are usually based on the peak rate sent over the interface (although average rate, volume or other measures may be used). For “transit” traffic, for example, there is generally a charge to be levied based on the peak rate at which the traffic arrives. The traffic on a transit interface may be monitored in 5 minute intervals, with the 95th percentile interval being used to indicate the rate to be used for charging.
For traffic carried under a “peering” arrangement, the monitoring, which may involve a similar or different measure being taken, may simply be used by one ISP to ensure that it isn't carrying significantly more (e.g. by a factor of three) of another ISP's traffic than that ISP is carrying of the first ISP's traffic.
In recent years the distinction between transit and peering has become confused. Most internet traffic is now originated at large service providers and CDNs (Content Delivery Networks). Some organisations, such as Level3 Networks are both transit providers and CDN operators. A network provider that had been operating under peering arrangements may find that a peering partner has become a content provider who might be expected to pay for its traffic to be carried, but who is (ab)using a peering arrangement for its traffic.
A recent example of this is the well-cited dispute between Comcast and Level3. Originally Netflix had contracted Akamai (a CDN) to deliver their traffic. Netflix paid Akamai who in turn paid Comcast. Netflix then moved to Level3 who were also a transit provider for Comcast. Netflix paid Level3, but Comcast then found themselves in the position of not receiving any payment for the Netflix traffic they were carrying, which was now coming from Level3. Level3 also receive transit payments from other ISPs who do not have as much bargaining power as Comcast for the same Netflix traffic. Comcast decided that Level3 were no longer acting as a transit provider and decided to start charging Level3.
Another defence that an ISP may attempt (in order to deter traffic from appearing over paid-for transit arrangements) is to operate transit interfaces at very high utilisations. This constrains the amount they pay to the transit provider and also encourages content providers and CDNs to negotiate direct peering arrangements with the ISP. The downside of such an approach is that it may also indiscriminately degrade the experience of the ISP's own subscribers.
While ISPs generally monitor what is going over their transit and peering interfaces (for example by observing the source and destination IP addresses and who owns them), many ISPs also use Deep Packet Inspection (DPI) to analyse and control the traffic passing through their networks.
The siting of any DPI system depends on the role it is intended to fulfil. Some ISPs site their DPI systems as close to the transit and peering points as possible. In this manner they can apply general policies to Internet traffic, but can also apply specific policies to an individual transit or peering arrangement. For example, peer-to-peer (P2P) traffic may be more heavily throttled on an expensive transit connection than on a free peering connection. By siting the DPI close to the ingress of the Internet traffic, however, the ISP loses the ability to analyse and control subscriber traffic that is turned around (e.g. subscriber to subscriber) or which has originated in the ISP's network (e.g. IP TV). Typically, tight control of an individual subscriber line (such as prioritising and shaping the traffic to fit into the subscriber line bandwidth) is not possible.
The above approach is shown in FIG. 1, which illustrates a scenario in which traffic policies are applied at ingestion points to manage transit/peering arrangements and costs. In FIG. 1, traffic arrives at an ISP network 10 either via one of a plurality of peering points 12 or via one of a plurality of transit points 14. Policy points 15 are located at some (or possibly all) of the peering points 12 and transit points 14, and may apply policies to the traffic they “see”. Unless blocked or redirected, the traffic 18 is then forwarded across the ISP network 10 and on towards its destination via one of a number of broadband subscriber access points (or “attachment points”) 16.
An alternative, pursued by many other ISPs is to site the DPI systems close to the subscriber lines themselves, for example co-located with the Broadband Remote Access Server (BRAS) where the broadband line is terminated. At this location the DPI system can inspect 100% of the user traffic and can be used to prioritise traffic and improve user experience (for example by prioritising voice and video traffic over file downloads). It can also be used to restrict the user line speed to offer reduced speed broadband products or apply security controls such as parental control and content filtering. However, siting the DPI system close to the subscriber (or indeed at any point deeper in the network than the transit and peering interfaces) means that traffic arriving over different transit and peering interfaces cannot be distinguished by the DPI system or in any subsequent analysis.
This alternative approach is shown in FIG. 2, which illustrates a scenario in which traffic policies are applied near subscribers to control subscriber experience and product. In FIG. 2, traffic again arrives at an ISP network 10 either via one of a plurality of peering points 12 or via one of a plurality of transit points 14. The traffic 18 is forwarded across the ISP network 10 and on towards one of a number of broadband subscriber access points (or “attachment points”) 16, but at some or all of these, policy points 25 are located which may apply policies to the traffic they “see”, which may result in sanctions or other actions being applied in respect of the traffic forwarded (or intended to be forwarded) to the respective (intended) destinations via the respective broadband subscriber access points 16.
It would be possible to implement more complex policies by running DPI or other accounting and/or control systems at multiple points in the network, each with separate policies (that apply specifically to either network transit/peering arrangements or subscriber policies). This approach would however be complex, and would be likely to be costly. It may also limit the types of policies that can be applied (e.g. it may not be possible to ensure that each user has a fair share of bandwidth if the traffic has already been pre-shaped at the transit/peering points). Putting traffic through multiple stages of enforcement can also have a negative impact on the Quality-of-Service (QoS) that a subscriber receives, by introducing network delays, for example.
European application EP2106068 discloses a technique for determining origin-specific network metrics in respect of a data network having at least one ingress node. Data items received from outside the network are forwarded with headers comprising fields for carrying origin information relating to the origin of the data item, and path metric information indicative of a characteristic being monitored. The data items are caused to traverse the network, and as they are doing so, the fields carrying path metric information are updated. After the data items have traversed the network, the origin information and path metric information are determined, and an origin-specific path metric relating to the characteristic in respect of the relevant portion of a path across the network is derived in dependence thereon. An origin-specific network metric is then determined by combining origin-specific path metrics derived in respect of different data items if they relate to characteristics in respect of data items having a common origin.